User talk:Drake178
Archive link Fortunately, no, the game can't generate maps where either of X=0 or X=59 are land (and that might even extend to the X=1 and X=58 tiles, don't remember). It's also something no modder should ever do - all the game code is written with the assumption that continents and land don't exist on tiles, AI naval movement definitely, but probably more, like city radius for resource tiles as well. These simply add or subtract 1 to check an adjacent tile, and if land was on the border, that results in invalid X coordinates (-1 or 60) which will like cause severe problems. Rivers in combat would be nice to see working, I noticed the graphics exist for them but aren't used. Not sure how they are supposed to behave though - if they are impassable for land units, that is pretty problematic for gameplay but if they merely cost 2-3 movement points to cross, that's fine. I don't remember why I gave up on trying to restore them, maybe because there was no defined movement cost or room to add one? Or maybe it seemed too time consuming? I always have too much to work on... SeravySensei (talk) 21:05, April 8, 2019 (UTC) :Actually, pretty much all of the code I've seen so far (AI naval, or AI in general, I have not) is written with the assumption that continents can wrap around the boundary. That includes every resource calculator. They add and subtract, yes, but then check tile validity afterwards, and adjust for wrapping. Rivers cost the same movement as rough tiles, except that they can be sailed in, which means normal cost for swimmers. There are no graphics for Myrran rivers though, and the tile types are scrambled by the combat background drawing function. One direction also doesn't generate properly (incorrect start location). And there might be other problems I haven't seen yet. =) Drake178 (talk) 00:06, April 9, 2019 (UTC) : : Proof of concept ;-) : Drake178 (talk) 08:51, April 12, 2019 (UTC) :: ::And this is why the original code only ever generates one river =P ::Drake178 (talk) 04:37, April 19, 2019 (UTC) ::: :::Nearly there ;-) :::Drake178 (talk) 00:18, April 27, 2019 (UTC) :: ::What else? =D ::Drake178 (talk) 04:16, April 29, 2019 (UTC) Thrown and Breath Attack Strength is now shown in the active unit window and combat unit display during battle For this, could you please post the image as a bmp or png or something the tweaker's "replace image" can use instead of raw hex data? (or mail the image) Unless this is one of those that can't be replaced using it... :That's not going to work unfortunately. Not just because the corrupted image has different dimensions (9x3 instead of 9x8), but I'm also having trouble saving it with the same palette and keeping transparency. I can probably do it in GIMP instead of Paint, but the tweaker still won't let me replace. I see two ways of working around that though, but it will take a day or two. :Drake178 (talk) 23:26, June 1, 2019 (UTC) Wrack patch: #1: Wrack no longer deals squared damage #2: Wraith Form no longer incorrectly protects from Wrack #3: Wrack is no longer erroneously limited to damaging 40 figures at a time #4: Wrack affecting more than 36 figures can no longer corrupt memory #4: Wrack will remove slain figures with more appropriate timing #5: Wrack's visual is now accompanied by a corresponding sound effect Is this compatible with CoM? It seems to have applied without issues (ofc lots of warnings) but I haven't checked if it uses the correct damage type and save modifier. :With this, I realized after the fact that it's been altered more than I thought in CoM. The resist part is not affected by the patch, so whatever you've changed there will work like before, but the patch does indeed do regular damage. Luckily, that's a 1-byte fix =D AE2FD F2 F6 :On the other hand, we may need to re-evaluate the Life Steal vs Irreversible Damage fix, because I don't think I've considered the scenario of having Irreversible Damage that is not equal to a full figure's hits, which Gates of Hades will result in. That being said, I think I was adding the extra damage rather than replacing anything, so in theory I think it should still work. :Drake178 (talk) 23:26, June 1, 2019 (UTC) Since you've already added a far call here, I also re-purposed that to make your "random" Death Demons actually random That's really bad news. The whole random Death Demon thing is a workaround to make sure it doesn't summon a unit with Caster 40 into a slot that doesn't support having the Caster ability. When casting spells, unit ID above 13h refers to a wizard casting the spell. So units combat summoned into those slots with Caster caused serious issues. This number is hardcoded in a lot of areas in the code, changing it is not realistic. So as a workaround, CoM will 'randomly" never summon a Caster Demon if they are in those slots. Making it actually random below that slot number is fair game of course. I can't apply this (and the next one that seems to require it) until this is fixed. Of course it can be included in 1.51 as is. :Oooh, so that's what the index < 19 was for? =D We'll have to add that back (I can do it later if you don't want to), but other than that nothing's changed. It should be at $75D21, with everything else (including the CoM special for animation difference) shifted down. However, it's probably actually easier to jump out of there into the nop section, do the index check there, and load ax with the random max value before jumping back if it's valid for caster. :Drake178 (talk) 23:26, June 1, 2019 (UTC) The human player can no longer cast spells that would increase their unit count over 9 in combat Not sure what this includes, fixing Possession, Confusion and Creature Binding? How exactly? Disabling stealing the unit? I believe I had a forum topic about this and the community consensus was "do not fix", so I'd like some more information before considering this one. See here : http://www.realmsbeyond.net/forums/showthread.php?tid=8269 :Well, to be perfectly honest, I consider the game's error message excessively straightforward in this regard. It reads: "You may only control 9 units in combat at one time." So even if you don't like this solution for CoM, please do include it for v1.51, as this is the canon solution. Besides, "Allowing one side to control more than 9 seems worse than the current buggy behavior." is also in that thread. :That being said, I'd love to brainstorm a different solution for this for CoM, so let's have at it! I'll get back to you with what I know once I've sorted out the breath image. :Drake178 (talk) 23:26, June 1, 2019 (UTC) :EDIT: Oh, Confusion will still allow you to temporarily have more than 9, that's one of the things in there. It considers confused units to belong to their original owner in all cases. Which does also result in you getting the 9 units error when you have 9, but 3 are temporarily controlled by the enemy. Anyway, if you still don't want to include it, at least make it optional later when I've written the rest of the missing parts =) :Drake178 (talk) 23:37, June 1, 2019 (UTC) Fixes bug: the AI can't cast Psionic Blast on units with Illusions Immunity This one is questionable. It should be fine for CoM because the AI picks a spell and target both based on expected damage using simulated spell attack rolls. But I don't think that was included in 1.51? In which case it risks doing very little damage for a very large amount of mp? I'll leave this up to you to decide, as I honestly have no idea how much of the AI improvements made it into 1.51. If you think it's safe and worth targeting the unit for the AI, let me know and I'll include it, otherwise it's better if the AI doesn't do stupid moves just because the rules allow it. :Even in v1.31, the AI evaluates direct damage spells by a simulated Attack Roll, albeit with an Attack Strength override of 25, so it will react in a similar way as CoM. The main problem I saw there is that if I'm attacking with low-level Undead or Death units, that don't have a high Defense anyway, the AI still won't blast them out of existence even when it has no better spells to use. :Drake178 (talk) 23:26, June 1, 2019 (UTC) Thank you very much for all these amazing patches, I'll upload the next RC as soon we deal with the above problems. SeravySensei (talk) 19:53, June 1, 2019 (UTC) :I'll keep it up, you're welcome! =D :Drake178 (talk) 23:26, June 1, 2019 (UTC) One more question, the combat rivers. I don't think this was included in the blog post (or maybe I missed it?), what is the movement cost of these tiles? When I tested it seemed to be 2 moves for walking and 1 for Flying units which is reasonable. Does it cost 1 for swimming and noncorporeal units as well? If I wanted to change the cost in CoM, where do I do that? CoM units have more movement so maybe a cost of 3 would be a better contribution to gameplay there? Unfortunately the overland cost of swamp and river is different so either way it won't be consistent I guess, unless we can have separate costs for the different sources of river tiles. (The moat might work better with a cost of 3 as well.) SeravySensei (talk) 11:18, June 2, 2019 (UTC) On Steam Cannons, the ranged attack strength appears at the wrong position after applying the two patches (displaying breath and displaying to hit), is this a problem on my side (I changed the / sign to display % instead) or is it a bug caused by the unit having no melee attack at all interfering with one of the patches? ~~ ~~ :Let's see. I failed to evaluate the consequences of not having a melee attack and used the drawing coordinates sequentially. Dang. That's definitely my fault, I apologize. I'll bring you a fix in a few. And I was so proud of that too =( :For the rivers, I think I just skimmed on the topic of Movement Allowance, or not even that. The gist is in my very first reply above, but that's not a real explanation. Movement costs per terrain type are set in the function at $DB3C8. For the river group, it's 4/2/4/2 (Gound1, Fly, Ground2, Swim, in half moves), set in the block at $DB49B. That's where you can change them. Swamps having separate costs is doable, but will require a bit more legwork. We either have to reuse the original could group or, more appropriately, invent our own. Then, have most of the generating functions treat both the same, except for the previously mentioned movement map generator, which can branch to a different block for them. There's loads of space there for that, but everywhere else I'll need to check. Still, as long as I don't fail to evaluate all of the consequences, it shouldn't be a problem =P :Speaking of evaluating consequences... I think Life Steal vs Irreversible Damage still won't cooperate with Gates of Hades with my second patch, only with the one that disables gaining extra hits completely. The original game can't create a scenario where Irreversible Damage is not a multiple of Hits per Fig (or 200), so I never thought about this. Without disabling extra healing, and reducing the amount healed to the amount healable, the Life Stealing unit will ignore Irreversible Damage in the block that restores its health no matter what. I think this can only be fixed inside the block itself, but before doing that, it'd be good to know what you think should happen in this scenario. "Best of both worlds" would mean that extra Hits can still be gained. In this case, the Irreversible Damage won't be healed, but instead be effectively replaced with temporary Hits. This should be doable by comparisons with the remainder of the Irreversible Damage, stopping the healing at that point and moving on to extra Hits. :Finally, for the record, that moat patch was highly experimental. Did you come up with a good idea on how to determine which Towns should have them? :Drake178 (talk) 19:18, June 2, 2019 (UTC) I kept the unintentional moving of the Ranged Attack Strength up to the melee position if the unit has no melee attack, as it actually provides better visibility/readability in my opinion. If you don't like it that way, let me know, and I'll get you a version that doesn't do this (I might write it anyway, but probably won't post it otherwise). I can't imagine anyone mistaking a cannon's attack as a melee one but for consistency I'd prefer that, yes. The same stat should always appear in the same place, that's more intuitive. (for this reason I also didn't include the one that moves ammo and mp if the unit has only one of them) Irrevesible damage, I asked on the forum, so far no meaningful replies. I see this as a design decision, not really a bugfix, and a complex one at that. There are plenty of ways "extra hits" could behave in theory (set A): #Split equally between figures, dead included. This would be consistent with effects that grant extra "base" hit points like Lionheart or Charm of Life, but would mean a major nerf to Life Steal and Exaltation for multiple figure units. I don't think this is a good choice. #Split equally between still living figures. Dead figures would then gain additional maximal health so a unit with less living figures would gain more maximal hit points but would be much less likely to reach that through regular healing. This is still a nerf, not recovering figures means less damage output. I don't really think there is a need for a nerf though. #Split equally between figures, excluding irrecoverable dead. This works on the assumtion that those figures can't get healed so any maximal hp on them not only is wasted like "1", but also won't turn into a "benefit" by raising maximal hp - those figures can't get healed to begin with. But there is another part to it (set B) : #Apply as if it was normal healing first, then as extra hit points. This is basically saying we allow healing irrecoverable dead with extra hp effects. Picking this makes the above choice irrelevant as there can't be dead figures in the unit when extra hp is distributed. #Or always apply as extra hit points, even if there is damage to cancel out. This means maximal hp increases and rounding down by figures happen, and figures can't revive. Horrible option for gameplay but best for consistency as buff type sources of extra hp (Lionheart, levels, Charm of Life etc) work this way already. #Apply as if it was normal healing first, but not cancel irrecoverable damage. Then apply the rest as extra hit points. This makes A1 not relevant and identical to A3. This is what currently happens. First we need to pick from the second set as it determines the choices available in the first. I rule out option B2, it pretty much makes Exaltation a useless spell for all but single figure units. B3 seems the most logical which forces picking A2 or A3 from the other group. Picking A3 seems better and I think that's what your patch is meant to do. No healing is lost but noirrecoverable figures are recovered. However we can also pick B1. Speaking of which I'm not entirely sure what actually happens currently? I got the impression it's B1 - extra hp canceling irrecoverable damage and reviving figures anyway, but not sure. Furthermore there is a third part to this, assuming we did pick the 3/3 options in the first two. What happens to figures that do have irrecoverable damage on them but are still alive? Here we have another 3 choices (set C) : #We treat them as irrecoverable dead so they are excluded from the healing. The consequence is a single figure unit can't ever heal even if it has taken a single point of irrecoverable damage.Very harsh. This makes these effects strictly better for multiple figure units. #We let them gain extra hp as if they were not affected. In this case said single figure unit is effectively recovering frm irrecoverable damage, the net result is no different from it getting healed. However this won't be true for multi-figure units, making these spells strictly superior on single figure units where taking damage didn't reduce the offensive capacity of the unit in the first place. #We draw an arbiraty line like "do 1 below half hp, 2 otherwise". This is not player friendly. I don't really see any good choices in this one which is probably my only reason to consider B1 or B2. Basically "extra hp" fundamentally contradits the concept of irrecoverable damage because if allowed, and if it doesn't completely override it (B1) or stops being a healing type effect (B2) then we need to draw an arbitary line somewhere on how much irrecoverable damage makes the healing fail and how. (Your answer is, whole figures, loss of offensive power isn't recovered by health is anyway. That's a valid option and means picking C2. But ultimately that still means we consiciously pick that completely healing irrecoverable damage on heroes or stage beetles is ok, but on halberdiers or wraiths it isn't and they need to stay penalized in their offensive power. Which also means reduced Life Steal capacity for the future as it is done per figure so that's actually a very singificant difference for wraiths and death knights.) Ultimately, I think all the possible options have drawbacks, but one has to be chosen. I don't see a good way out, and in these cases I tend to pick "do nothing" unless several people agree on preferring a specific option. Moats, for the time being, I like your idea of river or swamp tiles. Although I am worried it might make it easier to defend against the AI while it doesn't really help slowing down the human player, in which case disabling it altogether is best. (or coming up with a condition that is easier to achive for the AI. Choosing Swamp and river tiles is something the human is far better at, unfortunately.) Actually, how often do human players use walking melee units to attack a city? Not that often I think? The AI (and neutral monsters) do it all the time so moats are probably overall bad for the game. One of the most important current focus in CoM was to make sure heavier garrisons are necessary for humans and moats go against that design....unless, the condition is to have a large, expensive army garrisoning the city which AI players will have, humans usually not. But that doesn't make sense for flavor at all. I'm fine with both rivers and swamps having the same cost if it's not trivial to change. I'm yet to see how much impact the feature has on combat and benefits whom, AI or human players more. If it makes it easier for the AI to catch stalling human units then higher costs are better. If it ends up abused as "free earth to mud" by players then we better keep it at a cost of 2. I don't think it stopping the AI from successfully stalling is something to worry about, the AI only really manages to survive the 25 turns and retreat once in a blue moon and even then only if it had move 4-5 units, with just 1-2 survivors. SeravySensei (talk) 22:02, June 2, 2019 (UTC) ::"The same stat should always appear in the same place, that's more intuitive. (for this reason I also didn't include the one that moves ammo and mp if the unit has only one of them)" :That is a very sound argument... For CoM. Unfortunately, when it comes to MoM, it is fundamentally flawed. Here, the "same place" is where it is in v1.31, where some of us have been staring at it for the past 20 years. It was you who moved it from there, contradicting the above quote, to "fix" something that is arguably a very minor concern. In the original game, there are a total of 2 (unique, Hero) units that have both Mana and Ammo. As such, to me, it's common sense to come up with a solution that does not affect every other unit with Ammo in the game, regardless of which resource is put in the middle (or wherever else). I went with Mana because "MP" is shorter than "Ammo", allowing more space between the displayed values, which significantly improves readability. Moving Ranged to the Melee slot would have a similar, although less pronounced effect, but in this case, your point is still very valid, and I have to agree with you even though I'll use the other version for myself. :Irreversible Damage actually means something different in CoM than it does in MoM. With that in mind, I think you're right, and your "do nothing" approach is probably the best idea for CoM. In MoM, on the other hand, there is no concept of "ireccoverable damage". There are only irreversibly slain figures and units, regardless of how it's implemented. With that, a Wraiths unit that regains such a figure is essentially "breaking the rules", and reduces the value of effects like Dispel Evil, Banish, or even petrification attacks. Not that this last one should work on a Non-Corporeal unit in terms of flavor, but hell, it's magic! =P :To be perfectly honest, if I was writing a mod, I don't think I would stop at rivers/swamps/moats only having an effect on movement. What went through my head there was that I thought you're already applying some combat terrain effects, so rivers could have some of their own too. E.g. a ground melee troop standing in water will likely perform terribly against a unit of Lizardmen, both on attack and defense. Just a thought though. Either way, while it may not be "trivial" to make the movement costs different, I won't know that until I've looked. The drawing functions typically only look at the tile type index, not the terrain group, so I don't think it'll actually be that hard. I'll get back to you once I get to it anyway. And as I said, moats were a spur of the moment. Don't break your game balance just to put them in, I didn't expect them to be included anywhere, I wrote it for the picture. :Drake178 (talk) 01:02, June 3, 2019 (UTC) EDIT: Replaced! Ranged is shown at its original location. =) Applying this as is caused the game to crash. Am I supposed to undo the previous one first? I don't have the previous version to reverse apply it though. Do you have one that's incremental? In MoM, on the other hand, there is no concept of "ireccoverable damage". While the concept doesn't exist it's probably still possible to happen anyway. If you buff a unit with irrecoverable dead figures using Lionheart in combat, the figures each gain hit points but tracked damage amount doesn't change. So you end up with irrecoverable dead figures but less overall irrecoverable damage than their hp. Likewise, dispel Heroism and you end up having more irrecoverable damage than the total health of the figures. While the last one is only possible in theory, Crack's Call does a fixed 200 damage so a unit with more health would take irrecoverable damage as well. Actually with enough life stealing, you might have such a unit, even if unlikely. Outside CoM, you have Black Channells to change hp in combat too, so there are more than enough ways to have irrecoverable damage even if they are all indirect wats. What went through my head there was that I thought you're already applying some combat terrain effects, so rivers could have some of their own too. E.g. a ground melee troop standing in water will likely perform terribly against a unit of Lizardmen, both on attack and defense. Just a thought though. No, I prioritize AI playability highly, as any game mechanics the AI can't recognize are poor design in a game where you can only play against AI players. For something like that the AI would need to be able to position their units to take advantage of the mechnics, which is impossible even more than the simple straightforward thrown/breath ability - where my not so trivial conclusion was, if the AI actually knew how to position against them somehow, the game would be less fun, resulting in 2 armies staring at each other waiting for the other to move first (or worse, requiring more computing power to pick the best move than on a chess board... more importantly what kind of human player would want that much compexity in every single battle anyway when a game has hundreds of them.) ::"While the concept doesn't exist it's probably still possible to happen anyway." :That's true, but in none of those cases can the unit actually gain extra temporary hits, which means it can't break the rules and recover irreversibly lost figures, which is what the problem is the way I see it. Without Life+Death, you can't improve Hits for Life Stealing units, and the casters that may still be able to break the rules in theory are all single figures and can not trigger the issue. Cracks Call/Disintegrate vs +43 extra Hits does exist as a theoretical possibility, sure, which is why I never understood why damage was limited to 200 of any type but hit points were not. Although I'm not even sure what it would take to get that in practice without defeating the entire enemy force, but it's a clear design shortcoming. It's unrelated though, because to fix it, one would simply mark the unit as irreversibly slain, instead of dealing it 200 damage to it, which is another thing I have to ponder on at some point. Maybe they just didn't want to write another function to destroy units when they already had one. ::"any game mechanics the AI can't recognize are poor design in a game where you can only play against AI players" :That's a good point, I didn't think about that. Although the beauty of a probabilistic AI is exactly that it's typically possible to wait long enough for it to move, and some of us may even find it amusing, at least for a while. =D The 18 units limit Okay, so let's see what I can gather about the 18 units in battle limit. The ultimate reason behind it is this: ; loads the graphics for the figures of a given unit ; type into the specified allocation index of the EMM ; FIGUREX handle and test draws it into the small image ; GUI work area, returning the EMM figure index ; Attributes: bp-based frame ; int __cdecl far EMM_LoadFigureGFX(int Unit_Type,int Fig_Index) EMM_LoadFigureGFX proc far FileName= byte ptr -24h Fig_FileNo_String= byte ptr -10h Fig_IMGSeg_Table@= dword ptr -0Ah Fig_Header_Seg= word ptr -6 Fig_First_IMG_Entry= word ptr -4 Seg_Address= word ptr -2 Unit_Type= word ptr 6 Fig_Index= word ptr 8 000 55 push bp 002 8B EC mov bp, sp 002 83 EC 24 sub sp, 24h ; Integer Subtraction 026 56 push si 028 57 push di 02A 8B 76 08 mov si, bp+Fig_Index 02A 56 push si ; Fig_Index 02C 9A 7F 00 41 36 call j_EMM_FIGX_CreateHdr ; maps in and creates an LBX_Alloc_Space header in the ; EMM FIGUREX handle, at a total offset of 638h times ; the figure index, with a size of 637h paragraphs ; plus 1 for the header 02C 59 pop cx 02A F7 C6 01 00 test si, 1 ; Logical Compare 02A 75 07 jnz short loc_F9681 ; Jump if Not Zero (ZF=0) Each full figure graphic takes up 638h paragraphs in the EMS FIGUREX handle. In other words, around 25k. The allocated size of this handle is 28 pages of 16k each, for a total of ~450k. Since the original game is designed to run on a 4Mb machine, of which only 3 will be EMS, they couldn't reasonably go any higher and still keep the rest of the engine running. I'm pretty sure that the 2700 value came around with the premise that they want to leave some for the overlay manager too. Now, this is a bottleneck that I think I can actually remove under the assumption that the game will be played under DosBOX. Or, at least, I do know how to. However, one of my ultimate goals is to reduce the memory footprint of the game to a level where one can play it on a WinXP machine native with sound. And as of right now, I have no idea how much EMS can be gotten out of one of those (maybe Tumu will know). In any case, each extra figure requires allocating a little over a page and a half of EMS to this handle. Then the next problem is the "sandbox". This is the single largest memory block the game allocates, at 81,840 bytes (it's larger than a segment). This is used for literally all sorts of stuff, and is typically cleared immediately after. However, in certain situations, there is also "resident" stuff here, such as the minimap image data overland. Whenever a tactical battle starts (don't know about strategic yet), the sandbox is flushed, and then loaded with combat-related resident data and graphics of a total size of around 36k (~8F1h paragraphs). This is relevant here because at that marker do the "pre-drawn" figures live. That is, figures are not drawn directly from EMS. Instead, at the beginning of composing every single on-screen frame, they are pre-drawn into the sandbox, into allocations of 37h paragraphs (880 bytes) + 1 header paragraph each. This is done because a lot of other stuff is drawn from EMS, especially sprites that represent objects on the combat map. Since these are all drawn in a certain Z-depth order, without the pre-drawing, the computer would have to continuously keep swapping EMS handles in and out, which is really inefficient and slow. This was one of the few ways the devs managed to squeeze some fps out (they weren't very skilled in this field unfortunately). Anyway, in every function that relies on redrawing the combat screen during an animation, this space either needs to be free of everything else, or otherwise be saved and reloaded between each frame. As such, when combat spell animations are loaded into the sandbox, they typically reallocate this space before loading their corresponding graphic file. This means that to expand on the loaded figure count, every single spell animation needs to be evaluated and checked if it still fits into the sandbox. With 18 battle figures, the remaining space is just around 29,000 bytes. While this is more than enough to load every animation I could find (the largest ones are 12-13k), the only ways to know for sure are to either have a complete analysis, or test and see each one. As noted above, adding a single figure requires an extra 896 bytes in this allocation. Unfortunately, that's not enough either. For quick access to every individual figure space, their pointers are stored in an array in the data segment at offset 0xc550 (file address $359F0). There is one unused word after the 18, but that is followed by other pointers and combat variables. This means that to extend the array, it either needs to be moved somewhere else along with all references to it, or the same needs to be done to the stuff that follows it in the data segment. Last, but not least, as you pointed out to me, there is the problem of spellcasters in battle. As of yet, I couldn't really come up with an easy way of solving this issue. Naturally, I can find all of the places where this is done, and change the values to something more appropriate, like 50h. Except it's a lot of places. Not impossible though, so if we were to resolve the other problems, I might actually be willing to do this. In fact, this is likely the hardest part of it all. Or did I miss anything? Drake178 (talk) 02:31, June 3, 2019 (UTC) Naturally, I can find all of the places where this is done, and change the values to something more appropriate, like 50h. Except it's a lot of places. Not impossible though, so if we were to resolve the other problems, I might actually be willing to do this. In fact, this is likely the hardest part of it all. Or did I miss anything? Unfortunately the number is not only used for comparisons but for addressing memory and stuff, I remember there was one where instead of the usual address for wizard data, it added 13h*4C8h less, assuming the variable containing the wizard index is 13h higher. So you'd have to track down all the variables and registers ever containing the index and all of their uses. Since I've already tested the combination above up to and including the special (just not with over 18 units in the table =P), I know they work, so apply those first. Then this one. I've tested it that way now too, so no more "accidents". Maybe I applied them in the wrong order but after summoning a bunch of things in combat (doesn't matter if it's Phantom Beasts or any of the changed animation creatures), the game crashes at end of battle (hit done for 25 turns.) so for the time being I'm not including these in CoM. ::"I remember there was one where instead of the usual address for wizard data, it added 13h*4C8h less, assuming the variable containing the wizard index is 13h higher" :Yeah, I know, there's even a global variable storing a "caster ID". They are all in predictable places though. ::"... after summoning a bunch of things in combat ..." :That's odd, I was actually testing summoning Zombies with the caster Demons. I'll check again, maybe I've missed something. I'll also go ahead and combine them into one single patch to exclude an ordering issue. :Drake178 (talk) 14:44, June 3, 2019 (UTC)